LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207833

Failed test cases in LAVA job 207833 (SoC: kaanapali-mtp).

  Case 1: remoteproc

1. Failed case: remoteproc
2. Root cause: SoCCP (remoteproc0) is in "attached" state because it is a pre-booted processor that Linux attaches to (not boots), while the test expects all remoteproc instances to be in "running" state; ADSP and CDSP are Linux-booted and correctly show "running" state.
3. Possible fix: Update the remoteproc test script to recognize "attached" as a valid state for attach-mode remoteproc instances (e.g., SoCCP); modify the test to check for either "running" OR "attached" state, or maintain a per-subsystem expected-state map that accounts for SoCCP's attach-mode lifecycle.
4. Detail analysis attachment: failed_case_job207833_1_detailed.md

  Case 2: PCIe

1. Failed case: PCIe
2. Root cause: Test infrastructure issue — the PCIe functional test script expects platform-specific DT nodes or lspci output patterns that are not present on kaanapali-mtp, despite PCIe hardware being fully functional (Gen.3 x2 link up, devices enumerated at 0000:00:00.0 and 0000:01:00.0).
3. Possible fix: Update the PCIe test script in qcom-linux-testkit to handle kaanapali-mtp platform correctly by either (1) adding kaanapali-specific DT node patterns to the test, or (2) making the test check for actual PCIe functionality (link status, device enumeration) rather than platform-specific DT nodes.
4. Detail analysis attachment: failed_case_job207833_2_detailed.md

  Case 3: USBHost

1. Failed case: USBHost
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Restore dr_mode = "peripheral" in arch/arm64/boot/dts/qcom/kaanapali-mtp.dts and kaanapali-qrd.dts as a short-term fix to unblock the PR. For proper dual-role support, add usb-role-switch; property to the USB controller node and wire it to the pmic-glink connector via usb-role-switch = <&usb_role_switch_provider>; phandle, then add the role-switch provider node under pmic-glink. Verify host mode enumeration on kaanapali-mtp hardware before merging.
4. Detail analysis attachment: failed_case_job207833_3_detailed.md

  Case 4: ** BT_FW_KMD_Service (Bluetooth Firmware/KMD Service Test)

1. Failed case: ** BT_FW_KMD_Service (Bluetooth Firmware/KMD Service Test)
2. Root cause: ** PR-introduced regression in Bluetooth QCA driver (drivers/bluetooth/btqca.c) breaks WCN7850 firmware download on kaanapali-mtp — HCI vendor command 0xfc00 times out during TLV segment transmission, preventing firmware file qca/hmtbtfw20.tlv from loading successfully.
3. Possible fix: Revert or fix the firmware download logic changes in drivers/bluetooth/btqca.c introduced by this PR (specifically the qca_combine_nvm_calib() function and related TLV handling modifications) to restore WCN7850 compatibility; ensure QCC2072 support additions do not alter the firmware download command sequence for existing chipsets like WCN7850.
4. Detail analysis attachment: failed_case_job207833_4_detailed.md

  Case 5: WiFi_Firmware_Driver — Driver/Module Issue (ath12k_pci missing)

1. Failed case: WiFi_Firmware_Driver — Driver/Module Issue (ath12k_pci missing)
2. Root cause: The ath12k_pci kernel module is not built or not included in the kernel image. The PCIe WiFi device (17cb:110e WCN7850) is detected on the bus, but the ath12k_pci driver module that binds to it is missing from /lib/modules/7.2.0-01457-gf957a7795822/kernel/drivers/net/wireless/ath/ath12k/. CONFIG_ATH12K is enabled but CONFIG_ATH12K_PCI appears to be disabled or not built as a module, preventing the driver from probing the PCIe-attached WCN7850 WiFi hardware on kaanapali-mtp.
3. Possible fix: Enable CONFIG_ATH12K_PCI=m in the kernel configuration (arch/arm64/configs/defconfig or the relevant config fragment), rebuild the kernel, and verify that ath12k_pci.ko is present in the modules directory. The driver should then automatically probe the WCN7850 device at boot and create a WiFi interface.
4. Detail analysis attachment: failed_case_job207833_5_detailed.md

  Case 6: ** KVM Driver Initialization Failure — HYP mode not available

1. Failed case: ** KVM Driver Initialization Failure — HYP mode not available
2. Root cause: ** KVM driver cannot initialize because the Gunyah hypervisor is already running at EL2 (Exception Level 2), preventing KVM from obtaining the exclusive EL2 access it requires. On kaanapali-mtp, the boot firmware loads Gunyah hypervisor (version gunyah-mobile-ca9ade961) at EL2 before the Linux kernel boots, and KVM detects this condition during initialization and aborts with "HYP mode not available", preventing /dev/kvm device node creation.
3. Possible fix: This is a platform configuration issue, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978 (which contains no KVM-related changes). To enable KVM on kaanapali-mtp: (1) modify the boot firmware/bootloader configuration to NOT load the Gunyah hypervisor, allowing the kernel to boot directly at EL2, OR (2) use a different platform/board that does not have a hypervisor pre-loaded at EL2, OR (3) accept that KVM and Gunyah are mutually exclusive on this platform and mark KVM tests as "not applicable" for kaanapali-mtp in the CI test matrix.
4. Detail analysis attachment: failed_case_job207833_6_detailed.md

  Case 7: ** KVM_EL2_DTB

1. Failed case: ** KVM_EL2_DTB
2. Root cause: ** KVM cannot initialize because the CPU is running at EL1 instead of EL2. The bootloader (UEFI/XBL version 6.0.260226.BOOT.MXF_UEFI.2.5-00601-KAANAPALI-1) on kaanapali-mtp is configured to boot Linux at Exception Level 1, which prevents KVM from enabling hypervisor mode. The kernel correctly detects this condition and reports "HYP mode not available" at boot time [3.504518], resulting in /dev/kvm not being created. This is a platform configuration limitation specific to the kaanapali-mtp (SC8380XP) hardware/firmware, not a kernel bug or PR-introduced regression.
3. Possible fix: If KVM support is required on kaanapali-mtp: Coordinate with Qualcomm bootloader team to update UEFI/XBL firmware configuration to boot Linux at EL2 instead of EL1, and verify TrustZone secure monitor permits hypervisor mode operation. If KVM is not a requirement for this platform: Add platform-specific test skip logic in the LAVA job definition to exclude KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests when running on kaanapali-mtp, or mark these tests as expected failures in the test framework.
4. Detail analysis attachment: failed_case_job207833_7_detailed.md

  Case 8: KVM_Infra — Platform Virtualization Not Supported

1. Failed case: KVM_Infra — Platform Virtualization Not Supported
2. Root cause: The kaanapali-mtp platform does not support ARM Virtualization Extensions (EL2/HYP mode), which is required for KVM. KVM initialization fails with "HYP mode not available" at boot (timestamp 3.504518s), preventing /dev/kvm device creation.
3. Possible fix: Exclude KVM tests from the kaanapali-mtp LAVA job definition. Update the test suite configuration to skip KVM tests on platforms without EL2 support. Add a platform capability check in the test runner to automatically skip virtualization tests when /dev/kvm is unavailable due to missing hardware support (not driver failure).
4. Detail analysis attachment: failed_case_job207833_8_detailed.md

  Case 9: 0_qcom-next-ci-premerge-tests

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: KVM infrastructure test failed because /dev/kvm device node is not present. The kernel logged "kvm [1]: HYP mode not available" at boot, indicating that EL2 (hypervisor mode) is not available on the kaanapali-mtp platform, preventing KVM initialization. This is a pre-existing platform limitation, not a PR-introduced regression—the PR contains only documentation and device tree binding changes with no KVM or virtualization code modifications.
3. Possible fix: This is not a kernel bug requiring a fix. The kaanapali-mtp board does not support EL2/HYP mode, which is a hardware/firmware limitation. The test should either be skipped on platforms without EL2 support, or the test framework should be updated to mark this as "SKIP" rather than "FAIL" when CONFIG_KVM is enabled but /dev/kvm is unavailable due to missing HYP mode. No kernel changes are needed for this PR.
4. Detail analysis attachment: failed_case_job207833_9_detailed.md

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207834

Failed test cases in LAVA job 207834 (SoC: glymur-crd).

  Case 1: remoteproc

1. Failed case: remoteproc
2. Root cause: Test expectation mismatch — SoCCP remoteproc is correctly in "attached" state (early-boot processor that Linux attaches to) but the test incorrectly expects "running" state (Linux-controlled boot).
3. Possible fix: Update the remoteproc test script to accept "attached" as a valid state for remoteproc0 (soccp) on glymur-crd, since SoCCP is an early-boot RISC-V MCU that boots before Linux and is attached rather than started by the kernel.
4. Detail analysis attachment: failed_case_job207834_1_detailed.md

  Case 2: Probe_Failure_Check — Deferred Probe Storm (Driver Module Issue)

1. Failed case: Probe_Failure_Check — Deferred Probe Storm (Driver Module Issue)
2. Root cause: Eight PMIC temp-alarm devices (c426000.spmi:pmic@{1,2,3,5,7}:temp-alarm@a00 and c437000.spmi:pmic@{2,3,5}:temp-alarm@a00) remain in permanent deferred probe state with "(reason unknown)" because the qcom-spmi-temp-alarm driver is not loaded or not built into the kernel. The PR introduces a new qcom-spmi-mbg-tm driver and related Kconfig options (QCOM_SPMI_MBG_TM, QCOM_SPMI_ADC_TM5_GEN3) but does not ensure the existing temp-alarm driver remains available for glymur-crd's PMIC configuration. The regulatory.db firmware load failure is a known benign issue (cfg80211 regulatory database is optional).
3. Possible fix: Verify that CONFIG_QCOM_SPMI_TEMP_ALARM is enabled in the kernel configuration for glymur-crd. If the PR intentionally replaces the old temp-alarm driver with the new MBG driver, update the glymur-crd device tree to use the new compatible string and ensure the new driver's dependencies (QCOM_SPMI_ADC5_GEN3) are met. If both drivers should coexist, ensure both CONFIG_QCOM_SPMI_TEMP_ALARM and CONFIG_QCOM_SPMI_MBG_TM are enabled and the device tree nodes use the correct compatible strings for each PMIC type.
4. Detail analysis attachment: failed_case_job207834_2_detailed.md

  Case 3: ** smmu

1. Failed case: ** smmu
2. Root cause: ** The PR introduces a new Iris video codec device node (iris: video-codec@aa00000) in arch/arm64/boot/dts/qcom/glymur.dtsi without a top-level iommus property — IOMMU bindings are present only in child nodes (non-pixel and pixel sub-nodes), causing the parent device to not be attached to any IOMMU group, which fails the LAVA SMMU test's critical master validation check.
3. Possible fix: Add a top-level iommus property to the iris: video-codec@aa00000 node in arch/arm64/boot/dts/qcom/glymur.dtsi (e.g., iommus = <&apps_smmu 0x1940 0x0>, <&apps_smmu 0x1943 0x0>, <&apps_smmu 0x1944 0x0>, <&apps_smmu 0x19e0 0x0>;) to ensure the video codec device is attached to an IOMMU group, or update the LAVA test to accept child-node-only IOMMU bindings for multi-context devices like Iris.
4. Detail analysis attachment: failed_case_job207834_3_detailed.md

  Case 4: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure issue — no external USB devices physically connected to the glymur-crd board's USB host ports during test execution. The USB host controller (xHCI) initialized successfully and enumerated both USB 2.0 and USB 3.0 root hubs, but the test expects at least one functional USB device beyond the root hubs to be present.
3. Possible fix: This is not a kernel regression. The test should either: (1) be marked as SKIP when no USB devices are expected in the lab setup for glymur-crd, or (2) the lab infrastructure should ensure a USB device (e.g., USB flash drive, USB keyboard) is physically connected to the board's USB port before running the test. No kernel or PR changes are required.
4. Detail analysis attachment: failed_case_job207834_4_detailed.md

  Case 5: 0_qcom-next-ci-premerge-tests

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test infrastructure marked the test run as "unfinished" despite all individual test cases completing execution. The message "Marking unfinished test run as failed" at line 7303 indicates LAVA detected an unexpected test runner exit condition. Four individual test cases genuinely failed: (1) remoteproc - remoteproc0 in 'attached' state instead of expected 'running', (2) Probe_Failure_Check - deferred probe devices and regulatory.db firmware load failure, (3) smmu - video codec (aa00000.video-codec) missing iommu_group attachment, (4) USBHost - no functional USB devices detected (only hubs present).
3. Possible fix: Re-trigger the CI job to verify if the "unfinished test run" is a transient LAVA infrastructure issue. For the genuine test failures: (1) remoteproc0 'attached' state is expected behavior for certain remoteproc instances and may be a test expectation issue, not a kernel regression; (2) Probe_Failure_Check failures (deferred probes for temp-alarm devices and regulatory.db firmware) are known benign issues on this platform; (3) smmu failure for video codec missing iommu_group requires investigation of video codec driver probe sequence and DT iommus property; (4) USBHost failure requires physical USB device connection to the test board or test expectation adjustment.
4. Detail analysis attachment: failed_case_job207834_5_detailed.md

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207835

Failed test cases in LAVA job 207835 (SoC: qcs6490-rb3gen2).

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: The test detected three firmware load failures during boot: (1) regulatory.db for cfg80211 wireless regulatory database, and (2-3) modem.mbn for remoteproc0 (modem subsystem). These are expected missing firmware files on qcs6490-rb3gen2 in the current test environment configuration — regulatory.db is optional for wireless operation (WiFi functional tests passed), and modem firmware is not provisioned in this LAVA test image (modem subsystem is not required for baseport validation).
3. Possible fix: Update the Probe_Failure_Check test script to suppress known-benign firmware load failures for qcs6490-rb3gen2: add regulatory.db and qcom/qcs6490/modem.mbn to the platform-specific firmware exclusion list, as these files are not provisioned in the test rootfs and their absence does not indicate a kernel regression (WiFi_OnOff, WiFi_Firmware_Driver, BT_ON_OFF, and BT_FW_KMD_Service all passed, confirming wireless subsystem is functional).
4. Detail analysis attachment: failed_case_job207835_1_detailed.md

  Case 2: USBHost

1. Failed case: USBHost
2. Root cause: Test infrastructure issue — no external USB devices connected to the qcs6490-rb3gen2 board's USB host port during test execution. The USB host controller driver (dwc3-qcom) initialized successfully, USB core subsystem loaded correctly, and no kernel errors were logged. The test script enumerated USB devices and found none, which is expected behavior when no physical USB devices are attached to the host port.
3. Possible fix: This is not a kernel bug requiring a code fix. The failure is environmental. To resolve: (1) Verify the LAVA lab setup for qcs6490-rb3gen2 includes a USB device (e.g., USB flash drive, USB hub) connected to the USB host port before test execution, or (2) mark the USBHost test as SKIP for this board if USB host testing is not supported in the current lab configuration, or (3) update the test to check for USB host controller presence and capability rather than requiring enumerated devices.
4. Detail analysis attachment: failed_case_job207835_2_detailed.md

  Case 3: KVM_Driver — Platform Virtualization Support Unavailable

1. Failed case: KVM_Driver — Platform Virtualization Support Unavailable
2. Root cause: The qcs6490-rb3gen2 (Kodiak) platform does not support ARM virtualization extensions (EL2/Hypervisor mode). The kernel correctly detected this hardware limitation during KVM initialization with the message "kvm [1]: HYP mode not available" at boot time (3.401088s). While CONFIG_KVM is enabled in the kernel configuration, the underlying hardware does not provide the EL2 privilege level required for KVM operation, preventing the creation of /dev/kvm.
3. Possible fix: This is not a kernel bug or PR-introduced regression. The PR adds only documentation and device tree bindings (including EL2 overlays for platforms that DO support virtualization). To resolve: (1) Skip/disable KVM tests on qcs6490-rb3gen2 in the LAVA test suite, as this platform lacks hardware virtualization support, OR (2) Mark KVM tests as expected-fail for this platform, OR (3) Use a different Qualcomm platform with ARM virtualization extensions (e.g., SA8775P, SM8550) for KVM validation.
4. Detail analysis attachment: failed_case_job207835_3_detailed.md

  Case 4: ** KVM_EL2_DTB — Test Configuration Mismatch (EL1 DTB used, EL2 required)

1. Failed case: ** KVM_EL2_DTB — Test Configuration Mismatch (EL1 DTB used, EL2 required)
2. Root cause: ** The LAVA job flashed and booted the regular DTB (qcs6490-rb3gen2.dtb) which boots in EL1 mode. In EL1, KVM/HYP mode is architecturally unavailable on ARM64, causing the kernel to report kvm [1]: HYP mode not available at boot. The test KVM_EL2_DTB requires the board to boot in EL2 mode with the EL2 DTB overlay (qcs6490-rb3gen2-el2.dtb) to enable KVM support.
3. Possible fix: Update the LAVA job definition for qcs6490-rb3gen2 KVM tests to flash and boot the EL2 DTB (qcs6490-rb3gen2-el2.dtb) instead of the regular DTB. The EL2 DTB is now available in the build artifacts after this PR merges. Alternatively, create a separate LAVA device type or job template specifically for EL2/KVM testing on this platform.
4. Detail analysis attachment: failed_case_job207835_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Exclude KVM tests from the qcs6490-rb3gen2 test suite, as this platform is configured to run Linux as a guest VM under Gunyah and does not support nested virtualization. Alternatively, if KVM testing is required, reconfigure the board to boot Linux directly at EL2 without the Gunyah hypervisor.
4. Detail analysis attachment: failed_case_job207835_5_detailed.md

  Case 6: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM cannot initialize on qcs6490-rb3gen2 because the Gunyah hypervisor is already running at EL2, preventing KVM from taking control of the hypervisor mode — kernel message "kvm [1]: HYP mode not available" at boot confirms this platform limitation.
3. Possible fix: This is a pre-existing platform configuration issue, not a PR-introduced regression. The qcs6490-rb3gen2 board runs Gunyah hypervisor which occupies EL2, making KVM unavailable. To enable KVM testing: (1) boot without Gunyah hypervisor, or (2) exclude KVM tests from the CI test suite for Gunyah-enabled platforms, or (3) use a different board/configuration that does not run a proprietary hypervisor at EL2.
4. Detail analysis attachment: failed_case_job207835_6_detailed.md

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207836

Failed test cases in LAVA job 207836 (SoC: qcs615-ride).

  Case 1: Probe_Failure_Check — Firmware Load False Positive

1. Failed case: Probe_Failure_Check — Firmware Load False Positive
2. Root cause: The Probe_Failure_Check test detected a cfg80211 regulatory database firmware load failure (Direct firmware load for regulatory.db failed with error -2) that occurred during early boot. This is a benign false positive: the cfg80211 subsystem first attempts to load an optional user-space regulatory.db file; when absent (error -2 = -ENOENT), it falls back to compiled-in X.509 certificates, which loaded successfully as evidenced by the log line "Loading compiled-in X.509 certificates for regulatory database" immediately preceding the failure. The system continued normal operation with no WiFi/wireless functionality impairment. This failure is unrelated to the PR (which contains only audio subsystem changes) and is a pre-existing platform characteristic of the qcs615-ride test image.
3. Possible fix: Suppress this specific firmware load failure pattern in the Probe_Failure_Check test logic by adding an exception for regulatory.db when the preceding log shows successful loading of compiled-in certificates. Alternatively, if strict firmware-load checking is required, add the regulatory.db file to the rootfs firmware directory (/lib/firmware/) in the test image build recipe, though this is unnecessary for functionality.
4. Detail analysis attachment: failed_case_job207836_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The smmu test expects video codec sub-devices (aa00000.video-codec:video-decoder and aa00000.video-codec:video-encoder) to be attached to IOMMU groups, but these sub-devices are not present in the device tree or driver implementation for qcs615-ride. The parent device aa00000.video-codec is correctly attached to IOMMU group 6, but the test's expectation for child video-decoder and video-encoder devices to have separate IOMMU group attachments is not met. This is a test expectation mismatch, not an actual SMMU or kernel regression.
3. Possible fix: Update the smmu test to exclude video codec sub-device checks for qcs615-ride, or modify the test to only verify parent video-codec device IOMMU attachment. The PR does not introduce this issue — it is a pre-existing platform-specific test configuration problem where the test expects a device topology that qcs615 does not implement.
4. Detail analysis attachment: failed_case_job207836_2_detailed.md

  Case 3: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: QCS615 SoC does not support ARM EL2 (Hypervisor mode), which is required for KVM virtualization. Kernel correctly detected this during initialization and reported "HYP mode not available", preventing /dev/kvm device node creation.
3. Possible fix: Mark KVM_Driver, KVM_EL2_DTB, and KVM_Infra tests as SKIP (not FAIL) for qcs615-ride in the LAVA test suite, or add a platform capability check in the test runner to skip KVM tests when EL2 is unavailable.
4. Detail analysis attachment: failed_case_job207836_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: This is a platform architecture limitation, not a kernel bug. The qcs615-ride platform uses Gunyah as its hypervisor, which precludes KVM operation. To resolve: (1) Disable CONFIG_KVM in the kernel config for Gunyah-based platforms, or (2) Add KVM test skip logic in the CI test suite to skip KVM tests when running on Gunyah-based platforms (detect via /sys/hypervisor/type or boot log "Gunyah based bootup"), or (3) If nested virtualization under Gunyah is required, this needs Gunyah hypervisor support for nested EL2 virtualization (not currently available).
4. Detail analysis attachment: failed_case_job207836_4_detailed.md

  Case 5: ** KVM_Infra — KVM driver initialization failure (platform configuration issue)

1. Failed case: ** KVM_Infra — KVM driver initialization failure (platform configuration issue)
2. Root cause: ** The qcs615-ride platform boots with Gunyah hypervisor occupying ARM EL2 (Hypervisor mode). KVM requires exclusive EL2 access and cannot initialize when another hypervisor is present, resulting in "HYP mode not available" and no /dev/kvm device node creation.
3. Possible fix: Disable the KVM test suite for qcs615-ride in the LAVA job definition, as this platform is configured for Gunyah virtualization and cannot support KVM simultaneously. Alternatively, if KVM testing is required, reconfigure the platform firmware/bootloader to boot without Gunyah hypervisor (mutually exclusive choice).
4. Detail analysis attachment: failed_case_job207836_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on QCS615-Ride because Gunyah hypervisor is already running at EL2 (HYP mode), preventing KVM from accessing the required privilege level. The kernel message "kvm [1]: HYP mode not available" at boot time (3.236s) indicates KVM detected it cannot operate in this configuration. This is a platform configuration limitation, not a kernel bug or PR-introduced regression.
3. Possible fix: This is expected behavior on platforms running Gunyah hypervisor. To enable KVM testing: (1) reconfigure the platform to boot without Gunyah hypervisor, OR (2) exclude KVM tests from the CI test suite for QCS615-Ride targets running Gunyah, OR (3) use a different target platform that does not run a hypervisor at EL2 for KVM validation.
4. Detail analysis attachment: failed_case_job207836_6_detailed.md

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207837

Failed test cases in LAVA job 207837 (SoC: hamoa-evk).

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected deferred probe entries for 8 PMIC temp-alarm devices and two known-benign probe/firmware failures (qcom_qseecom_uefisecapp -EBUSY, regulatory.db -ENOENT) that do not impact system functionality on hamoa-evk.
3. Possible fix: Suppress these known-benign failures in the Probe_Failure_Check test for hamoa-evk: (1) temp-alarm deferred probe is expected when thermal framework initializes after SPMI PMIC probes; (2) qcom_qseecom_uefisecapp -EBUSY is a known platform limitation where UEFI secure app is not available; (3) regulatory.db firmware absence is benign when WiFi/BT functional tests pass (confirmed: WiFi_OnOff, BT_ON_OFF, BT_SCAN all passed).
4. Detail analysis attachment: failed_case_job207837_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device aa00000.video-codec is not attached to any IOMMU group, failing the SMMU test's critical master protection validation on hamoa-evk (X1E80100 SoC).
3. Possible fix: Add the missing iommus property to the video-codec device tree node at aa00000.video-codec in the hamoa-evk DTB, referencing the appropriate SMMU instance and stream ID, following the pattern used for other critical masters (GPU, Display, UFS) on this platform.
4. Detail analysis attachment: failed_case_job207837_2_detailed.md

  Case 3: KVM_Driver — Platform Configuration Incompatibility

1. Failed case: KVM_Driver — Platform Configuration Incompatibility
2. Root cause: KVM cannot initialize on hamoa-evk (IQ-X7181) because the platform runs under Gunyah hypervisor at EL2. Kernel correctly reports "kvm [1]: HYP mode not available" at boot (line 4.856151). ARM architecture allows only one hypervisor at EL2; nested virtualization is not supported on this platform.
3. Possible fix: Exclude KVM tests from hamoa-evk LAVA job definition. This is expected behavior, not a regression. KVM tests should only run on platforms without a pre-existing hypervisor (bare-metal or platforms with nested virtualization support).
4. Detail analysis attachment: failed_case_job207837_3_detailed.md

  Case 4: ** KVM_EL2_DTB — /dev/kvm not available (HYP mode not supported)

1. Failed case: ** KVM_EL2_DTB — /dev/kvm not available (HYP mode not supported)
2. Root cause: ** The hamoa-evk platform does not support or enable ARM EL2 (Hypervisor Exception Level), as evidenced by the kernel message kvm [1]: HYP mode not available at boot time (4.856s). Without EL2, the KVM subsystem cannot initialize, and /dev/kvm is never created. This is a hardware/firmware limitation specific to the hamoa-evk board configuration, not a kernel regression.
3. Possible fix: This is a pre-existing platform limitation, not a PR-introduced regression. To enable KVM on hamoa-evk: (1) Verify the SoC hardware supports EL2/virtualization extensions; (2) Update the bootloader/UEFI firmware to boot the kernel at EL2 instead of EL1 (current UEFI version: BOOT.MXF_UEFI.2.5-00625-HAMOA-1); (3) If the hardware does not support EL2, mark KVM tests as "not applicable" for this platform in the CI test matrix. No kernel code changes are required.
4. Detail analysis attachment: failed_case_job207837_4_detailed.md

  Case 5: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver initialization failed because HYP (Hypervisor) mode (EL2) is not available on the hamoa-evk platform — the kernel logged "kvm [1]: HYP mode not available" during boot, preventing /dev/kvm device node creation.
3. Possible fix: This is a platform hardware/firmware limitation, not a kernel regression. The hamoa-evk board does not support virtualization extensions (EL2/HYP mode). Either: (1) skip KVM tests on hamoa-evk in the CI test matrix, or (2) enable EL2 support in the platform firmware/bootloader if the SoC hardware supports it but firmware is configured to boot at EL1.
4. Detail analysis attachment: failed_case_job207837_5_detailed.md

  Case 6: 0_qcom-next-ci-premerge-tests

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test definition marked as failed due to 5 genuine individual test failures within the suite: Probe_Failure_Check (probe errors for temp-alarm devices and qseecom_uefisecapp), smmu (video codec aa00000.video-codec missing iommu_group attachment), and 3 KVM tests (KVM_Driver, KVM_EL2_DTB, KVM_Infra all failing because /dev/kvm device node is not present despite CONFIG_KVM being enabled).
3. Possible fix: The overall test case failure is expected LAVA behavior when individual tests fail. Address the root causes: (1) For KVM failures: investigate why /dev/kvm is not created despite CONFIG_KVM=y - check if KVM driver initialization is failing or if the platform lacks required hardware virtualization support (EL2/VHE); (2) For smmu failure: verify video codec driver IOMMU binding in device tree and ensure video codec probe completes successfully; (3) For Probe_Failure_Check: investigate temp-alarm probe deferrals and qseecom_uefisecapp -EBUSY error - these may be pre-existing platform issues unrelated to this PR.
4. Detail analysis attachment: failed_case_job207837_6_detailed.md

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207838

Failed test cases in LAVA job 207838 (SoC: qcs9100-ride).

  Case 1: Kernel Crash — Watchdog Pretimeout Panic

1. Failed case: Kernel Crash — Watchdog Pretimeout Panic
2. Root cause: PR introduces CONFIG_WATCHDOG_PRETIMEOUT_DEFAULT_GOV_PANIC=y in kernel configuration, which triggers a kernel panic when the watchdog pretimeout event fires. The qcs9100-ride platform's watchdog pretimeout fired at 166 seconds during boot while systemd was starting services (Modem Manager, Network Manager, etc.), causing the system to panic instead of continuing operation.
3. Possible fix: Remove CONFIG_WATCHDOG_PRETIMEOUT_DEFAULT_GOV_PANIC=y from the kernel configuration and either set CONFIG_WATCHDOG_PRETIMEOUT_DEFAULT_GOV_NOOP=y or disable watchdog pretimeout governor entirely. Alternatively, if watchdog pretimeout panic is intentional for debugging, increase the watchdog timeout value or ensure the watchdog is properly serviced during boot.
4. Detail analysis attachment: failed_case_job207838_1_detailed.md

  Case 2: Kernel Crash — Watchdog pretimeout panic during boot

1. Failed case: Kernel Crash — Watchdog pretimeout panic during boot
2. Root cause: Watchdog pretimeout panic triggered at 166 seconds after boot start on qcs9100-ride. System was stuck in idle state waiting for multiple systemd services (Modem Manager, Network Manager, Hostname Service, Avahi mDNS/DNS-SD, Bluetooth OBEX, EFI mount) that failed to complete initialization within their timeout windows. The watchdog pretimeout fired because the system was not making forward progress, with CPU0 in cpuidle_enter_state when the interrupt occurred.
3. Possible fix: This is a userspace service initialization hang, not a kernel crash introduced by the PR. The PR contains only documentation and device tree binding changes with no code modifications that would affect boot flow or watchdog behavior. Re-trigger the CI job to verify if this is a transient infrastructure issue. If the hang persists, investigate why systemd services are timing out during boot on qcs9100-ride — check for network configuration issues, missing firmware files, or hardware dependencies that prevent service initialization. Consider increasing systemd service timeouts or disabling non-critical services for CI boot testing.
4. Detail analysis attachment: failed_case_job207838_2_detailed.md

  Case 3: Kernel Crash — Watchdog pretimeout panic during userspace boot hang

1. Failed case: Kernel Crash — Watchdog pretimeout panic during userspace boot hang
2. Root cause: System hang during userspace initialization at ~167 seconds after boot; multiple systemd services (Modem Manager, Network Manager, Hostname Service, Avahi, EFI mount) blocked for >1 minute, preventing forward progress; watchdog pretimeout triggered panic on CPU0 from idle state (cpuidle_enter_state), indicating the system was unable to complete boot and reach login prompt on qcs9100-ride.
3. Possible fix: Investigate why systemd services are hanging during boot — check for deadlocks in device initialization (modem, network, hostname resolution), filesystem mount issues (EFI partition mount failed with "logical sector size too small"), or missing firmware/dependencies; increase watchdog timeout temporarily to allow boot completion for debugging; check dmesg for service-specific errors before the hang; verify all required kernel drivers and firmware are present for qcs9100-ride platform services.
4. Detail analysis attachment: failed_case_job207838_3_detailed.md

  Case 4: Kernel Crash — Watchdog Pretimeout Panic

1. Failed case: Kernel Crash — Watchdog Pretimeout Panic
2. Root cause: Watchdog bark (pretimeout) triggered a kernel panic while the system was idle in cpuidle. The watchdog pretimeout event fired on CPU0 at 166.954682 seconds after boot, indicating the watchdog was not being serviced (pet) for an extended period, causing the pretimeout governor to panic the system. The system successfully booted, reached userspace, started systemd services, but then hung or became unresponsive during idle, preventing the watchdog from being pet.
3. Possible fix: This is a pre-existing kernel/platform issue unrelated to the PR changes (which are primarily audio/sound subsystem and device tree additions). The watchdog timeout configuration may be too aggressive for this qcs9100-ride platform, or there is a latent bug causing the system to hang during idle. Short-term mitigation: increase the watchdog timeout value in the device tree or kernel command line, or disable the watchdog pretimeout panic governor. Proper fix: investigate why the system became unresponsive during idle — check cpuidle driver behavior, interrupt delivery, and scheduler activity on qcs9100-ride. Enable ftrace or add debug instrumentation to capture the system state before the watchdog fires.
4. Detail analysis attachment: failed_case_job207838_4_detailed.md

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207839

Failed test cases in LAVA job 207839 (SoC: sm8750-mtp).

  Case 1: ** Probe_Failure_Check (suppressed — known benign)

1. Failed case: ** Probe_Failure_Check (suppressed — known benign)
2. Root cause: ** The Probe_Failure_Check test detected two firmware load failures (bluetooth qca/hmtnv20.b2c and regulatory regulatory.db) during early boot, but both BT_ON_OFF and WiFi_OnOff functional tests passed, confirming firmware loaded correctly at runtime. This is a known false positive caused by the test probing firmware state before drivers fully initialize.
3. Possible fix: No action required. This is a known benign test infrastructure issue covered by suppression rules 2 and 3 in lava-known-benign-failures.md. The functional tests confirm the kernel is working correctly on sm8750-mtp.
4. Detail analysis attachment: failed_case_job207839_1_detailed.md

  Case 2: ** PCIe (Test Infrastructure Issue - Not a Kernel Bug)

1. Failed case: ** PCIe (Test Infrastructure Issue - Not a Kernel Bug)
2. Root cause: ** The PCIe test script's validation logic does not match the sm8750-mtp hardware configuration. The kernel PCIe subsystem is fully functional (driver loaded at qcom-pcie 1c00000.pcie, link established as PCIe Gen.2 x2 link up at 10.321s, devices enumerated: Root Port 0000:00:00.0 [17cb:011c] and Endpoint 0000:01:00.0 [17cb:1107], IOMMU integration successful), but the test script's checks for DT node presence, lspci "Capabilities:" string, and driver load state fail due to test implementation assumptions that don't align with this platform's actual configuration.
3. Possible fix: Update the PCIe test script in qcom-linux-testkit (Runner/suites/Kernel/Baseport/PCIe/run.sh) to correctly detect PCIe functionality on sm8750-mtp by: (1) adjusting DT node path checks to search for qcom,.*-pcie compatible strings under /proc/device-tree/soc*/pcie*/ rather than hardcoded paths, (2) updating lspci parsing to use lspci -v for capabilities detection, and (3) verifying driver load by checking /sys/bus/platform/drivers/qcom-pcie/*/ for bound devices rather than relying on module load state (driver may be built-in on sm8750).
4. Detail analysis attachment: failed_case_job207839_2_detailed.md

  Case 3: ** USBHost (Test Infrastructure / Hardware Availability Issue)

1. Failed case: ** USBHost (Test Infrastructure / Hardware Availability Issue)
2. Root cause: ** The sm8750-mtp board in the LAVA lab does not have any USB host peripherals (keyboard, mouse, storage device, or hub) physically connected to its USB host port. The USBHost test checks for enumerated USB devices via lsusb or /sys/bus/usb/devices and fails when none are found. The USB host controller driver (dwc3-qcom for device a600000.usb) initialized successfully and the device was added to IOMMU group 4, but no external USB devices are plugged in.
3. Possible fix: This is not a kernel bug. To make the USBHost test pass, physically connect a USB peripheral (e.g., USB storage device, keyboard, or hub) to the USB host port on the sm8750-mtp board in the LAVA lab. Alternatively, mark the USBHost test as SKIP (not FAIL) for sm8750-mtp if USB host hardware is intentionally not available on this board variant, or update the test to distinguish between "driver not loaded" (genuine failure) and "no devices connected" (expected for boards without USB host peripherals).
4. Detail analysis attachment: failed_case_job207839_3_detailed.md

  Case 4: KVM_Driver

1. Failed case: KVM_Driver
2. Root cause: KVM device node /dev/kvm is not available because the kernel is running at EL1 (guest mode) under the Gunyah hypervisor on SM8750-MTP, not at EL2 (hypervisor mode) which is required for KVM functionality. Nested virtualization is not supported in this configuration.
3. Possible fix: This is not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978. The failure is expected behavior on SM8750-MTP which runs under Gunyah hypervisor. To enable KVM testing: (1) boot the kernel directly at EL2 without a hypervisor, or (2) use a platform that supports nested virtualization, or (3) exclude KVM tests from the SM8750-MTP test suite as they are not applicable to this hypervisor-based platform configuration.
4. Detail analysis attachment: failed_case_job207839_4_detailed.md

  Case 5: ** KVM_EL2_DTB

1. Failed case: ** KVM_EL2_DTB
2. Root cause: ** KVM cannot initialize on sm8750-mtp because the system is running under the Gunyah hypervisor, which occupies EL2 (the hypervisor privilege level required by KVM). Linux is running at EL1 as a guest VM, and KVM requires exclusive EL2 access to create the /dev/kvm device node. This is an architectural constraint, not a kernel bug.
3. Possible fix: Add a pre-test check in the KVM test suite to skip KVM tests when Gunyah hypervisor is detected (check for "gunyah" in dmesg or device tree). Long-term: maintain separate test configurations for sm8750-mtp — one with Gunyah (skip KVM tests) and one bare-metal (run KVM tests) — or disable Gunyah in bootloader for platforms where KVM testing is required.
4. Detail analysis attachment: failed_case_job207839_5_detailed.md

  Case 6: KVM_Infra (and related KVM_Driver, KVM_EL2_DTB)

1. Failed case: KVM_Infra (and related KVM_Driver, KVM_EL2_DTB)
2. Root cause: KVM cannot initialize on SM8750-MTP because Gunyah hypervisor is already running at EL2; KVM requires exclusive EL2 access and cannot coexist with another hypervisor on ARM64 architecture.
3. Possible fix: This is not a kernel regression but an expected architectural limitation. To enable KVM testing on SM8750-MTP, boot the system without Gunyah hypervisor (requires firmware/bootloader configuration change to disable Gunyah and allow Linux to run at EL2). Alternatively, skip KVM tests on platforms configured with Gunyah hypervisor.
4. Detail analysis attachment: failed_case_job207839_6_detailed.md

  Case 7: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM cannot initialize on SM8750-MTP because Gunyah hypervisor (Type-1) is already running at EL2, preventing KVM (Type-2) from accessing virtualization extensions. CONFIG_KVM is enabled but /dev/kvm device node is never created because the KVM driver detects it cannot operate under an existing hypervisor.
3. Possible fix: This is expected behavior, not a bug. To enable KVM testing on SM8750-MTP: (1) disable Gunyah hypervisor in the firmware/bootloader configuration, or (2) use a different test platform without Gunyah, or (3) mark KVM tests as "skip" for SM8750-MTP in the LAVA job definition since this platform is configured for Gunyah-based virtualization, not KVM-based virtualization.
4. Detail analysis attachment: failed_case_job207839_7_detailed.md

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207840

Failed test cases in LAVA job 207840 (SoC: monaco-evk).

  Case 1: ** Probe_Failure_Check

1. Failed case: ** Probe_Failure_Check
2. Root cause: ** WiFi driver (ath11k_pci) probe failed with error -110 (ETIMEDOUT) because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the Monaco EVK test rootfs (error -2: ENOENT). The MHI bus cannot power up the WCN6855 WiFi chip without firmware, causing the probe sequence to timeout. This is a pre-existing test infrastructure issue, not a PR-introduced regression — the PR contains only documentation and device tree binding changes with no driver code modifications.
3. Possible fix: Update the Monaco EVK test rootfs to include the WCN6855 nfa765 variant firmware files. Install ath11k/WCN6855/hw2.1/nfa765/amss.bin (and associated .mdt/.b* files) into /lib/firmware/ in the test image. Verify the linux-firmware-ath11k package in the Yocto build recipe includes the nfa765 board variant. After updating the rootfs, reflash Monaco EVK and re-run the test — WiFi probe should succeed and Probe_Failure_Check should pass.
4. Detail analysis attachment: failed_case_job207840_1_detailed.md

  Case 2: SMMU Fault — Unhandled context fault with Runtime PM usage count underflow

1. Failed case: SMMU Fault — Unhandled context fault with Runtime PM usage count underflow
2. Root cause: SMMU 15200000.iommu experienced an unhandled context fault (fsr=0x402, iova=0x40100000, fsynr=0x130011) indicating a translation fault during a write operation to an unmapped or incorrectly mapped IOVA, immediately followed by a Runtime PM usage count underflow error suggesting improper power management reference counting in the SMMU driver or client device during the fault handling path on monaco-evk.
3. Possible fix: This is a pre-existing platform/driver issue not introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978 (which only adds SMMU compatible strings for new SoCs). The failure occurs during fastrpc compute-cb device probe when ADSP remoteproc is initializing. Immediate action: suppress this known monaco-evk SMMU fault in CI test expectations. Long-term fix: investigate SMMU context bank 0 mapping for fastrpc compute-cb@3 device at probe time, verify IOMMU domain attachment sequence and IOVA allocation correctness, and audit Runtime PM get/put pairing in arm-smmu driver fault handler and fastrpc driver probe path.
4. Detail analysis attachment: failed_case_job207840_2_detailed.md

  Case 3: ** USBHost

1. Failed case: ** USBHost
2. Root cause: ** The monaco-evk board's USB ports are configured in USB gadget (device) mode, not USB host mode. The test expects to enumerate USB host devices (via lsusb or similar), but no USB devices are physically connected to the board's USB host ports, or the ports are operating in gadget mode. Evidence: systemd reached "Hardware activated USB gadget" target (line showing USB gadget activation), and the test immediately reports "No USB devices found" without any USB host controller enumeration messages.
3. Possible fix: This is a test infrastructure issue, not a PR-introduced kernel bug. The PR does not modify USB host drivers or device tree USB configuration for monaco. To resolve: (1) verify the monaco-evk board has USB devices physically connected to its USB host ports in the LAVA lab, (2) confirm the device tree configures the USB ports in host mode (not gadget/OTG mode), or (3) mark this test as "not applicable" for monaco-evk if the board does not support USB host mode in the current lab configuration.
4. Detail analysis attachment: failed_case_job207840_3_detailed.md

  Case 4: WiFi_Firmware_Driver

1. Failed case: WiFi_Firmware_Driver
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add the missing nfa765 firmware files to the rootfs build. The firmware directory /lib/firmware/ath11k/WCN6855/hw2.1/nfa765/ must be populated with amss.bin and other required firmware blobs. This is a build/packaging issue, not a kernel code regression — the PR correctly maps monaco-evk to nfa765 firmware, but the firmware files are not included in the Yocto/distro image.
4. Detail analysis attachment: failed_case_job207840_4_detailed.md

  Case 5: WiFi_OnOff — ath11k_pci probe failure

1. Failed case: WiFi_OnOff — ath11k_pci probe failure
2. Root cause: ath11k_pci driver probe failed with error -110 (ETIMEDOUT) on monaco-evk because the required firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin is missing from the rootfs, causing MHI power-up timeout during WiFi device initialization.
3. Possible fix: Add the missing firmware file ath11k/WCN6855/hw2.1/nfa765/amss.bin to the rootfs firmware directory /lib/firmware/. This is a rootfs/build configuration issue, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978.
4. Detail analysis attachment: failed_case_job207840_5_detailed.md

  Case 6: 0_qcom-next-ci-premerge-tests

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: The overall LAVA test definition failed because multiple individual test cases failed within it. The primary root cause is PR-introduced: the ath11k driver probe fails with -ETIMEDOUT because the PR changes the firmware path for monaco-evk to use "nfa765" firmware (ath11k/WCN6855/hw2.1/nfa765/amss.bin), but this firmware file is not present in the rootfs. Additionally, the PR's SMMU driver changes introducing interconnect bandwidth voting cause a Runtime PM usage count underflow and SMMU context fault at iova=0x40100000.
3. Possible fix: Revert the ath11k firmware path change for monaco-evk in drivers/net/wireless/ath/ath11k/core.c (line 1054) back to the default firmware path, OR ensure the nfa765 firmware files are included in the rootfs image. For the SMMU issue, review the arm_smmu_icc_enable/disable implementation in drivers/iommu/arm/arm-smmu/arm-smmu.c to ensure proper PM reference counting balance when interconnect bandwidth voting is enabled/disabled.
4. Detail analysis attachment: failed_case_job207840_6_detailed.md

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207841

Failed test cases in LAVA job 207841 (SoC: lemans-evk).

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test detected deferred probe devices (4 SPMI PMIC temp-alarm devices at c440000.spmi:pmic@{0,2,4,6}:temp-alarm@a00) and firmware load failures (regulatory.db, qca/wcnhpbtfw21.tlv, qca/hpbtfw21.tlv) during boot; however, BT_ON_OFF and WiFi_OnOff functional tests both passed, confirming that Bluetooth and WiFi firmware loaded correctly at runtime and the devices are fully functional.
3. Possible fix: The firmware load failures are known benign false positives (suppression Rule 3 applies: BT ON/OFF passed). The deferred probe warnings for temp-alarm devices indicate a missing dependency (likely IIO thermal channel provider not yet probed); this is a pre-existing platform issue unrelated to the PR changes (PR touches audio/coresight/DT bindings but not thermal alarm drivers). No action required for this PR; the test should be updated to suppress firmware false positives when functional tests pass, and to allow deferred probe for temp-alarm devices on lemans-evk.
4. Detail analysis attachment: failed_case_job207841_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: The PR introduces a new video-codec@aa00000 device node in glymur.dtsi (used by lemans-evk) with iommus properties only on child nodes (non-pixel, pixel), but the parent platform device itself lacks an iommus property, causing the device to not be attached to any IOMMU group. The smmu test validates that critical masters have IOMMU protection and correctly flags this as a configuration error.
3. Possible fix: Add an iommus property to the parent video-codec@aa00000 device node in arch/arm64/boot/dts/qcom/glymur.dtsi, or if the device is intentionally using child-node-only IOMMU mappings (common for video codecs with separate pixel/non-pixel contexts), update the smmu test to recognize this pattern and check child node IOMMU attachments instead of expecting a parent-level attachment.
4. Detail analysis attachment: failed_case_job207841_2_detailed.md

  Case 3: 0_qcom-next-ci-premerge-tests

1. Failed case: 0_qcom-next-ci-premerge-tests
2. Root cause: LAVA test suite completed with 2 genuine test case failures (Probe_Failure_Check and smmu) that are pre-existing platform issues unrelated to the PR changes, which contain only documentation and device tree binding updates with no functional code modifications.
3. Possible fix: These failures are not PR-introduced regressions. The PR can proceed to merge. For the underlying issues: (1) Probe_Failure_Check: investigate temp-alarm deferred probe on PMICs and missing firmware files (regulatory.db, bluetooth firmware); (2) smmu: investigate why video codec device aa00000.video-codec is not attached to an IOMMU group on lemans-evk.
4. Detail analysis attachment: failed_case_job207841_3_detailed.md

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207842

Failed test cases in LAVA job 207842 (SoC: qcs8300-ride).

  Case 1: Hung Task Deadlock — UFS devfreq rwsem writer starvation

1. Failed case: Hung Task Deadlock — UFS devfreq rwsem writer starvation
2. Root cause: Rwsem deadlock between UFS devfreq scaling (writer) and qtee_supplicant BSG I/O (reader) on qcs8300-ride. The devfreq_monitor worker (kworker/u34:4:244) attempts to acquire the UFS host write lock via ufshcd_devfreq_scale → down_write, but qtee_supplicant:2555 holds a read lock on the same rwsem while blocked in blk_execute_rq → wait_for_completion_io_timeout waiting for a UFS BSG ioctl to complete. Multiple writeback workers are also blocked waiting for block I/O tags (blk_mq_get_tag), creating cascading I/O stalls. The system cannot make forward progress, preventing login prompt from appearing.
3. Possible fix: This is a pre-existing kernel issue unrelated to the PR (which only fixes DT binding YAML syntax). The deadlock is caused by a known UFS driver locking issue where devfreq scaling and BSG I/O paths contend on the host rwsem. Workaround: disable UFS devfreq (echo userspace > /sys/class/devfreq/*/governor) or apply upstream UFS locking fixes that separate devfreq and I/O paths. The PR changes (documentation-only) do not introduce or fix this issue.
4. Detail analysis attachment: failed_case_job207842_1_detailed.md

  Case 2: auto-login-action

1. Failed case: auto-login-action
2. Root cause: Kernel booted successfully but userspace failed to reach login prompt due to filesystem I/O hang — multiple tasks (systemd-timesyn, jbd2/sdf1-8) blocked for >122 seconds waiting on ext4 journal operations on the rootfs partition (/dev/sdf1), preventing system initialization from completing.
3. Possible fix: This is a pre-existing kernel/storage stack issue unrelated to the PR (PR contains only documentation and device tree binding changes, no storage/filesystem code). Re-trigger the LAVA job; if the hang recurs, investigate UFS driver or ext4/jbd2 journal commit path on qcs8300-ride — check for known issues with KIOXIA THGJFGT0T25BAZZA UFS device on this platform, verify UFS firmware version, and consider enabling additional debug (hung_task_panic, jbd2 debug) to capture the exact I/O stall point.
4. Detail analysis attachment: failed_case_job207842_2_detailed.md

  Case 3: minimal-boot

1. Failed case: minimal-boot
2. Root cause: Storage I/O subsystem deadlock — UFS device became unresponsive causing multiple kernel worker threads (writeback, devfreq, block layer) to block indefinitely waiting for I/O completion; qtee_supplicant (TrustZone userspace daemon) blocked on UFS BSG ioctl while holding a read lock needed by devfreq worker, creating a cascading deadlock that prevented login prompt from appearing within the 168-second LAVA timeout.
3. Possible fix: This is a pre-existing kernel/platform issue unrelated to the PR changes (audio subsystem modifications). Re-trigger the CI job; if the hang recurs, investigate UFS driver stability on qcs8300-ride — check for missing firmware, UFS controller initialization issues, or TrustZone/UFS interaction bugs. Consider increasing the LAVA login timeout from 168s to 300s as a temporary mitigation to allow slower boot scenarios to complete.
4. Detail analysis attachment: failed_case_job207842_3_detailed.md

  Case 4: Login Timeout — System Hang (UFS I/O Deadlock)

1. Failed case: Login Timeout — System Hang (UFS I/O Deadlock)
2. Root cause: Kernel booted successfully but userspace hung during init due to a UFS storage I/O deadlock involving qtee_supplicant blocking on UFS BSG requests while multiple writeback workers are blocked waiting for storage I/O completion, preventing the system from reaching a login prompt.
3. Possible fix: This is a kernel-level UFS driver or TrustZone interaction issue causing I/O stalls on qcs8300-ride. Investigate the UFS driver's interaction with qtee_supplicant (TrustZone secure storage operations) and the devfreq scaling path that is blocked on rwsem. Check if PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978 introduces any clock/power-domain changes affecting UFS PHY or controller initialization that could cause I/O timeouts. Re-run the test with UFS debug enabled (CONFIG_SCSI_UFS_QCOM_DEBUG=y) and collect full dmesg showing UFS command timeouts and hung task backtraces.
4. Detail analysis attachment: failed_case_job207842_4_detailed.md

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207843

Failed test cases in LAVA job 207843 (SoC: shikra-iqs-evk).

  Case 1: GIC

1. Failed case: GIC
2. Root cause: Test script bug — the GIC test script assumes 8 CPUs and attempts to parse timer interrupt counts for CPUs 4-7, but the shikra-iqs-evk platform only has 4 CPUs (CPU0-CPU3), causing bash integer comparison errors and false test failures for non-existent CPUs.
3. Possible fix: Update the GIC test script (/lava-207843/0/tests/0_qcom-next-ci-premerge-tests/Runner/suites/Kernel/Baseport/GIC/run.sh) to dynamically detect the number of online CPUs from /sys/devices/system/cpu/online or /proc/cpuinfo instead of hardcoding an assumption of 8 CPUs, and only validate timer counts for CPUs that actually exist on the platform.
4. Detail analysis attachment: failed_case_job207843_1_detailed.md

  Case 2: remoteproc

1. Failed case: remoteproc
2. Root cause: Modem remoteproc (remoteproc0) enabled in device tree but not configured for auto-boot; firmware path set to qcom/shikra/cqs/qdsp6sw.mbn but remoteproc subsystem never attempts to power up the modem, leaving it in "offline" state.
3. Possible fix: Add missing device tree property to trigger auto-boot for modem remoteproc, or verify that the modem firmware file exists at the specified path and that all required dependencies (clocks, regulators, memory regions) are properly configured in the shikra-iqs-evk device tree.
4. Detail analysis attachment: failed_case_job207843_2_detailed.md

  Case 3: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Could not be determined confidently from available logs.
3. Possible fix: Add the audiocorecc DT node to arch/arm64/boot/dts/qcom/shikra-iqs-evk.dts with correct reg, clocks, and compatible string per the new binding. Remove or prevent cpufreq-dt instantiation on shikra (check DT cpufreq node and platform code) since shikra uses qcom,shikra-cpufreq-rimps.
4. Detail analysis attachment: failed_case_job207843_3_detailed.md

  Case 4: PCIe

1. Failed case: PCIe
2. Root cause: PCIe controller driver not probing on shikra-iqs-evk — test reports "DT node is not present" and "Driver is not loaded". Kernel sync_state messages reference PCIe device at 45e8000.pcie, but no driver probe occurs. This is a pre-existing platform limitation, not a PR-introduced regression (PR only adds DT binding documentation, not driver or DT node).
3. Possible fix: This is not a kernel bug requiring a fix. The PCIe test failure is expected on shikra-iqs-evk until: (1) PCIe driver support for qcom,shikra-pcie compatible is added to pcie-qcom.c, (2) PCIe DT node is added and enabled in shikra-iqs-evk.dts, and (3) board hardware supports PCIe. Mark this test as expected-fail or skip for shikra-iqs-evk in CI configuration until PCIe enablement is complete.
4. Detail analysis attachment: failed_case_job207843_4_detailed.md

  Case 5: USBHost

1. Failed case: USBHost
2. Root cause: USB host controller (dwc3_qcom/xhci) did not probe or initialize during boot on shikra-iqs-evk, resulting in no USB devices being enumerated when the test ran; this is a hardware/infrastructure/configuration issue, not a kernel crash or PR-introduced regression.
3. Possible fix: Verify USB host controller driver is enabled in kernel config (CONFIG_USB_DWC3_QCOM, CONFIG_USB_XHCI_HCD); check device tree for usb@4e00000 node status and dependencies (clocks, regulators, PHYs); verify physical USB hardware is connected to the test board; if driver is present but not probing, check dmesg for deferred probe or missing dependency errors; re-run test with USB device physically connected to the board's USB host port.
4. Detail analysis attachment: failed_case_job207843_5_detailed.md

  Case 6: ** KVM_Driver

1. Failed case: ** KVM_Driver
2. Root cause: ** KVM driver initialization failed because ARM Hypervisor (EL2) mode is not available on the Shikra IQS EVK platform. The bootloader/firmware does not enable EL2 for Linux, preventing KVM from creating the /dev/kvm device node. This is a platform limitation, not a kernel bug or a regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978.
3. Possible fix: Mark the KVM_Driver test as "skip" or "expected to fail" on Shikra IQS EVK in the LAVA test definition, since the platform does not support KVM. Alternatively, contact the Qualcomm platform team to request a firmware update that enables EL2 for Linux on this SoC.
4. Detail analysis attachment: failed_case_job207843_6_detailed.md

  Case 7: KVM_EL2_DTB — /dev/kvm unavailable (KVM initialization failed)

1. Failed case: KVM_EL2_DTB — /dev/kvm unavailable (KVM initialization failed)
2. Root cause: KVM failed to initialize during boot because HYP (Hypervisor/EL2) mode is not available on the Shikra IQS EVK platform. Boot log shows "kvm [1]: HYP mode not available" at timestamp 3.394310s, preventing /dev/kvm device node creation. This is a platform/firmware limitation, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978.
3. Possible fix: This is not a PR-introduced regression. The Shikra IQS EVK platform does not support KVM/virtualization in its current firmware/bootloader configuration. To enable KVM: (1) verify the platform supports EL2/HYP mode in hardware, (2) ensure the bootloader (ABL/UEFI) boots the kernel at EL2 instead of EL1, (3) if the platform fundamentally lacks EL2 support, mark KVM tests as "skip" for this SoC in the CI test matrix rather than "fail".
4. Detail analysis attachment: failed_case_job207843_7_detailed.md

  Case 8: Kernel Crash — Synchronous External Abort in qcom_rng driver

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: The qcom_hwrng test triggered a synchronous external abort (hardware bus error) at PC qcom_rng_read+0xb8/0x210 when attempting to read from the hardware RNG device registers. The abort occurred during a memory-mapped I/O read operation (ldr w26, [x28, #0] - instruction b940039a), indicating the hardware RNG block is either not powered/clocked correctly, not present, or the MMIO mapping is incorrect for the Shikra IQS EVK platform.
3. Possible fix: Verify the qcom_rng device tree node for Shikra IQS EVK: confirm the reg property points to the correct MMIO base address for the PRNG hardware block on this SoC, ensure required clocks (core, iface) and power domains are specified and functional, and check that the hardware block is not disabled or gated. If the hardware RNG is not present or functional on Shikra IQS EVK, disable the qcom_rng driver for this platform or mark the DT node as status = "disabled".
4. Detail analysis attachment: failed_case_job207843_8_detailed.md

  Case 9: Kernel Crash — Synchronous External Abort in qcom_rng driver

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: The PR introduces a new RNG device tree node (rng@4454000) for Shikra with compatible string qcom,shikra-trng, but the qcom_rng driver attempts to access hardware registers that are either not powered, not clocked, or mapped to an invalid/inaccessible address, resulting in a synchronous external abort (bus error) when the qcom_hwrng test reads from /dev/hwrng.
3. Possible fix: The RNG device node added in the PR is missing required properties (clocks, power-domains, or interconnects) that must be enabled before the hardware can be accessed. Add the missing clock, power-domain, and/or interconnect references to the rng@4454000 node in arch/arm64/boot/dts/qcom/shikra-*.dtsi, following the pattern used in other Qualcomm SoC device trees (e.g., sc7280, sm8450). Verify the correct register base address (0x04454000) matches the hardware documentation for Shikra.
4. Detail analysis attachment: failed_case_job207843_9_detailed.md

  Case 10: Kernel Crash — synchronous external abort in qcom_rng driver

1. Failed case: Kernel Crash — synchronous external abort in qcom_rng driver
2. Root cause: The qcom_hwrng test triggered a synchronous external abort (hardware bus error) at qcom_rng_read+0xb8/0x210 when attempting to read from the TRNG hardware registers. The PR adds shikra-trng DT binding support, but the hardware MMIO region is either not powered, not clocked, or the base address is incorrect for the shikra-iqs-evk platform, causing the CPU to fault when the driver attempts MMIO read access.
3. Possible fix: Verify the TRNG MMIO base address (0x4454000 per the PR patch) matches the shikra-iqs-evk hardware specification and is correctly mapped in the device tree. Ensure the TRNG hardware block has its clocks enabled and power domain active before the driver probe. Add runtime PM or explicit clock/regulator enablement in the qcom_rng driver probe path for shikra. If the MMIO address is wrong, correct it in arch/arm64/boot/dts/qcom/shikra-*.dts.
4. Detail analysis attachment: failed_case_job207843_10_detailed.md

  Case 11: Kernel Crash — Synchronous External Abort in qcom_rng driver

1. Failed case: Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: Hardware bus access fault (synchronous external abort 0x96000010) in qcom_rng_read() at offset +0xb8 when accessing MMIO register during /dev/hwrng read operation. The qcom_hwrng test triggered a read from /dev/hwrng which caused the qcom_rng driver to access an invalid or unpowered hardware register address, resulting in a fatal bus error and kernel panic on shikra-iqs-evk.
3. Possible fix: Verify the TRNG hardware register base address and clock/power domain configuration in the shikra device tree. The PR adds "qcom,shikra-trng" compatible string support — ensure the DT node at rng@4454000 has correct reg property, required clocks are enabled, and the TRNG power domain is active before driver probe. If the hardware block is not present or powered on shikra-iqs-evk, mark the DT node as status = "disabled" or add runtime power management checks in the driver probe path.
4. Detail analysis attachment: failed_case_job207843_11_detailed.md

  Case 12: ** Kernel Crash — Synchronous External Abort in qcom_rng driver

1. Failed case: ** Kernel Crash — Synchronous External Abort in qcom_rng driver
2. Root cause: ** The PR adds a new RNG device node (rng@4454000) for Shikra, but the hardware block is not accessible. When the qcom_hwrng test attempts to read from /dev/hwrng, the driver tries to access the RNG hardware registers and triggers a synchronous external abort at qcom_rng_read+0xb8. This indicates the hardware block is either unpowered, unclocked, at the wrong address, or missing required DT dependencies (clocks, power-domains, interconnects).
3. Possible fix: Add the missing clock, power-domain, and interconnect properties to the rng device tree node in arch/arm64/boot/dts/qcom/shikra.dtsi. Reference the upstream qcom,prng.yaml binding schema and other working SoC examples (e.g., sm8450, sm8550) to identify required properties: clocks, clock-names, power-domains, and interconnects. Verify the MMIO address 0x4454000 is correct from Shikra hardware documentation. After fixing the DT, rebuild the DTB and re-test on Shikra hardware.
4. Detail analysis attachment: failed_case_job207843_12_detailed.md

LAVA job: https://lava-oss.qualcomm.com/scheduler/job/207844

Failed test cases in LAVA job 207844 (SoC: purwa-evk).

  Case 1: Probe_Failure_Check

1. Failed case: Probe_Failure_Check
2. Root cause: Test flagged expected platform-specific probe failures and missing optional firmware files as errors; none are PR-introduced regressions - qcom-pcie link training failures occur when no PCIe endpoints are present (hardware-dependent), qcom_qseecom_uefisecapp probe failure is a TrustZone configuration issue, and video codec firmware files are not included in the test rootfs image.
3. Possible fix: Suppress known benign probe failures in the Probe_Failure_Check test for purwa-evk platform: PCIe probe failures with -ENODATA when no endpoints present, qcom_qseecom_uefisecapp -EBUSY errors, and missing optional firmware files (regulatory.db, vpu30_p1_s7.mbn); alternatively, update test to distinguish between critical probe failures (that break functionality) and expected platform-specific failures.
4. Detail analysis attachment: failed_case_job207844_1_detailed.md

  Case 2: smmu

1. Failed case: smmu
2. Root cause: Video codec device (aa00000.video-codec) is missing IOMMU group attachment on purwa-evk platform — the device is present in the device tree but not attached to any IOMMU group, causing the SMMU validation test to fail when checking critical DMA master protection.
3. Possible fix: Add the missing iommus property to the video-codec@aa00000 device tree node in the purwa platform DTS file to bind the video codec to an IOMMU group, following the pattern used for other critical masters (GPU, UFS, USB) which successfully show IOMMU group attachments in the test log.
4. Detail analysis attachment: failed_case_job207844_2_detailed.md

  Case 3: ** KVM_Driver (Platform Configuration Issue — Gunyah Hypervisor Present)

1. Failed case: ** KVM_Driver (Platform Configuration Issue — Gunyah Hypervisor Present)
2. Root cause: ** KVM cannot initialize on purwa-evk because the Gunyah hypervisor has claimed EL2 (ARM hypervisor exception level) at boot. KVM requires exclusive access to EL2 to create and manage virtual machines, but Gunyah is already running at EL2. The kernel correctly detects this condition and prints "kvm [1]: HYP mode not available" at boot, preventing /dev/kvm from being created.
3. Possible fix: This is not a bug requiring a code fix. This is a platform configuration decision. To enable KVM on purwa-evk, the Gunyah hypervisor must be disabled in the boot firmware/bootloader configuration. Specifically, remove or disable hypvm.mbn from the flash image (spinor/hypvm.mbn). Alternatively, exclude KVM tests from the test suite for platforms that run Gunyah, as KVM and Gunyah are mutually exclusive.
4. Detail analysis attachment: failed_case_job207844_3_detailed.md

  Case 4: KVM_EL2_DTB

1. Failed case: KVM_EL2_DTB
2. Root cause: KVM cannot initialize because the kernel is running at EL1 (Exception Level 1) instead of EL2, which is required for KVM/hypervisor functionality. The system boots under the Gunyah hypervisor ("Gunyah based bootup" in UEFI logs), which runs at EL2 and launches the kernel at EL1, preventing KVM from accessing EL2 (HYP mode). The kernel reports "kvm [1]: HYP mode not available" at boot, and consequently /dev/kvm is never created.
3. Possible fix: This is not a PR-introduced regression—the PR contains no KVM, virtualization, or EL2-related changes (only device tree interconnect updates, AEST debugfs, and STP policy documentation). The failure is a platform configuration issue specific to purwa-evk running under Gunyah hypervisor. To enable KVM on this platform, either: (1) boot the kernel directly at EL2 without Gunyah (requires bootloader/firmware changes to disable Gunyah and boot kernel at EL2), or (2) use nested virtualization if Gunyah supports it (requires Gunyah hypervisor configuration changes). For CI purposes, suppress this test on purwa-evk when Gunyah is enabled, or run it only on platforms that boot the kernel at EL2.
4. Detail analysis attachment: failed_case_job207844_4_detailed.md

  Case 5: KVM_Infra — Platform EL2 Unavailable

1. Failed case: KVM_Infra — Platform EL2 Unavailable
2. Root cause: The purwa-evk platform firmware boots Linux at EL1 (kernel mode) instead of EL2 (hypervisor mode), preventing KVM from initializing. KVM on ARM64 requires the CPU to run at EL2 to provide virtualization support. Evidence: kernel log line 3189 shows "kvm [1]: HYP mode not available"; CONFIG_KVM is enabled (line 6667) but /dev/kvm is not created (line 6674) because KVM's is_hyp_mode_available() check fails at EL1.
3. Possible fix: This is a platform/firmware limitation, not a PR-introduced regression (PR 978 contains no KVM, boot, or EL2 code changes). Short-term: Mark KVM tests as skip/expected-fail for purwa-evk in the LAVA job definition to prevent false CI failures. Long-term: Update purwa-evk bootloader/firmware (ABL/UEFI) to hand off to Linux at EL2 instead of EL1; coordinate with Qualcomm BSP team. Verify fix by confirming "kvm [1]: Hyp mode initialized successfully" in dmesg and /dev/kvm device node creation.
4. Detail analysis attachment: failed_case_job207844_5_detailed.md

  Case 6: KVM_Infra

1. Failed case: KVM_Infra
2. Root cause: KVM driver initialization failed because HYP (EL2 hypervisor) mode is not available on the Purwa IoT EVK platform. The kernel message kvm [1]: HYP mode not available at boot time (4.7s) indicates the CPU is not running with EL2 enabled or the platform firmware/bootloader did not preserve EL2 mode for the kernel.
3. Possible fix: This is a platform/firmware limitation, not a kernel regression introduced by PR Prepare qcom-next based on tag 'Linux 7.2' of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git #978. The PR does not modify KVM or ARM virtualization code. To enable KVM on Purwa EVK: (1) verify the SoC supports virtualization extensions (ARMv8.0-A with VHE or later), (2) ensure the bootloader (ABL/UEFI) boots the kernel at EL2 (not EL1), and (3) if using Gunyah hypervisor (reserved memory regions present in DT), ensure it's configured to allow KVM in the primary VM. If KVM is not a requirement for this platform, mark the KVM tests as expected-to-skip for Purwa EVK in the CI configuration.
4. Detail analysis attachment: failed_case_job207844_6_detailed.md